Trusted database authentication through an untrusted intermediary

ABSTRACT

A method, system and computer-usable medium are disclosed for validating user credentials submitted to a data source by an untrusted intermediary. An untrusted intermediary attempts to access a data source on behalf of a user. The untrusted intermediary challenges the user to provide credentials of the type and format required to access the data provided by the data source. The user&#39;s trust client connects to an authentication service and identification credentials of the required type and format are generated. The identification credentials are conveyed to the user&#39;s trust client, which then provides them to the user&#39;s client, which in turn conveys them to the untrusted intermediary. The untrusted intermediary then presents the identification credentials to an authentication plug-in of the data source. The authentication plug-in validates the authenticity of the provided credentials with their associated authentication service. Once the credentials are successfully validated, the requested data is provided to the user&#39;s client by the untrusted intermediary.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the disclosure relate in general to the field ofcomputers and similar technologies, and in particular to softwareutilized in this field. Still more particularly, it relates to thevalidation of user credentials submitted to a data source by anuntrusted intermediary.

2. Description of the Related Art

The way in which Web-based information is aggregated, assembled, andpresented continues to evolve. In the early days of the Internet,content was treated as static elements that were assembled, typically byusing hypertext markup language (html) code, to create Web pages. Later,technologies such as JavaServer Pages and Active Server Pages, weredeveloped to allow software developers to dynamically generate HTML,extensible markup language (XML), or other types of documents inresponse to a Web client request. Today, content that exists indifferent formats can be retrieved from multiple sources on the Web andbe combined into a mashup to create entirely new and innovativeservices. Further, through the use of AJAX and other Web applicationsinformally known as Web 2.0, individual content elements within a Webpage can be updated in near-real-time without refreshing the entire Webpage.

However, current methods of creating mashups can introduce securityconcerns. As one example, Web browsers typically incorporate asame-origin policy as a security feature that is used to keep maliciouscode hosted on a Web site within one domain from requesting data, suchas stored credentials, from a site on another domain. As a result, thesame-origin policy forces Web applications used in mashups to eithersacrifice security or functionality. Another security issue associatedwith mashups is the submission of user credentials for authenticationand authorization. A mashup, acting as an intermediary for a user, maynot be able to send user credentials to a data source with its requests.This may be due to the user and the data source not fully trusting themashup as an intermediary, or the mashup not having the ability tosupply the user's credentials to the data source in a compatible format.As one example of a data source, databases are not well equipped todayto perform this validation/transformation step. Current solutionstypically employ trusted intermediaries to store database authenticationcredentials and supply them to the database on behalf of the user.Storing user credentials with an untrusted mashup intermediary makesthem subject to compromise, and as a result, the authenticity of theuser's identity likewise becomes untrusted.

One potential approach to addressing this issue is to have theintermediary repeatedly prompt the user for secrets to authenticatetheir identity, which is inconvenient for the user, and also exposes thesecrets to compromise by the intermediary if it is untrusted. Anotherknown approach is the Google Account Authentication Proxy for WebApplications, which can accept identity tokens generated by astand-alone authentication server to authenticate a user. However, whileit will accept an identity token submitted by an intermediary on behalfof a user, all submitted credentials must be of the same type andformat. Furthermore, the back-end service for validating the submittedcredentials must reside in the same administration domain as the datasource. Yet another known approach is the Yale information TechnologyServices (ITS) Central Authentication Service (CAS). It is similar innature to the Google service described above, with the addition ofsingle sign-on. In view of the foregoing, there is a need for preservingthe broad creative freedom that mashup intermediaries offer while makingthem safer to use. This need extends beyond the user authenticationrequired for a mashup intermediary to access a subscription-based publicdata source to include trustworthy access to secure corporate datasources, such as databases. In particular, there is a need to accept thesubmission of a variety of security token formats from a mashupintermediary and not require that the back-end service providing theuser credentials be in the same administration domain as the datasource.

BRIEF SUMMARY OF THE INVENTION

The present invention includes, but is not limited to, a method, systemand computer-usable medium for validating user credentials submitted toa data source by an untrusted intermediary. In various embodiments, auser's client accesses an untrusted intermediary for the provision ofdata from a data source. In one embodiment, the untrusted intermediaryis a mashup. As used herein, a mashup is generally defined as thecombining of content in various formats and from multiple sources forpresentation as a Web page. In these and other embodiments, theuntrusted intermediary attempts to access the data source on behalf ofthe user. In one embodiment, the data source is a database. In variousembodiments, user credentials are required to access the data providedby the data source. When they are required, the untrusted intermediarychallenges the user to provide credentials of the required type andformat. The user's trust client then connects to an authenticationservice and is authenticated. In one embodiment, the authenticationservice is a security token service (STS) operable to generate securitytokens implemented with the WS-Trust protocol. Once the user isauthenticated, the user's trust client requests identificationcredentials of the required type and format from the STS.

In one embodiment, the STS generates identification credentials of therequired type and format. In another embodiment, the STS is unable toprovide identification credentials of the required type and format, soidentification credentials of an alternate type and format aregenerated. Once the identification credentials are generated, they areprovided to the user's trust client, which in turn provides theidentification credentials to the user's client, which then conveys theidentification credentials to the untrusted intermediary. In turn, theuntrusted intermediary presents the user's identification credentials toan authentication plug-in of the data source. In one embodiment, if theprovided identification credentials are not of the required type andformat, they are rejected by the authentication plug-in. In anotherembodiment, the authentication plug-in transforms identificationcredentials that are not of the required format and type into the formatand type required by the data source.

In one embodiment, the authentication plug-in processes the providedidentification credentials determine their issuing STS, which is thenused to validate the authenticity of the credentials. In one embodiment,the STS is in a different management domain than the authenticationplug-in and the data source. In another embodiment, the untrustedintermediary presents user credentials of the required format and typedirectly to the data source. The data source then validates the provideduser credentials with a local authentication service. If the provideduser identification credentials are successfully validated, theuntrusted intermediary requests the desired data from the data source,which is then provided. In turn, the requested data is presented to theuser's client by the untrusted intermediary. The above, as well asadditional purposes, features, and advantages of the present inventionwill become apparent in the following detailed written description.

BRIEF DESCRIPTION OF THE DRAWINGS

Selected embodiments of the present invention may be understood, and itsnumerous objects, features and advantages obtained, when the followingdetailed description is considered in conjunction with the followingdrawings, in which:

FIG. 1 depicts an exemplary client computer in which the presentinvention may be implemented;

FIG. 2 shows the validation of user credentials submitted to a datasource by an intermediary with the security token service that issuedthe credentials;

FIGS. 3 a-c are a flowchart for validating user credentials submitted toa data source by an intermediary with the security token service thatissued the credentials;

FIG. 4 shows the validation of user credentials submitted to a datasource by an intermediary with a local authentication service; and

FIGS. 5 a-b are a flowchart for validating user credentials submitted toa data source by an intermediary with a local authentication service.

DETAILED DESCRIPTION

A method, system and computer-usable medium are disclosed for validatinguser credentials submitted to a data source by an untrustedintermediary. As will be appreciated by one skilled in the art, thepresent invention may be embodied as a method, system, or computerprogram product. Accordingly, embodiments of the invention may beimplemented entirely in hardware, entirely in software (includingfirmware, resident software, micro-code, etc.) or in an embodimentcombining software and hardware. These various embodiments may allgenerally be referred to herein as a “circuit,” “module,” or “system.”Furthermore, the present invention may take the form of a computerprogram product on a computer-usable storage medium havingcomputer-usable program code embodied in the medium.

Any suitable computer usable or computer readable medium may beutilized. The computer-usable or computer-readable medium may be, forexample, but not limited to, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, device,or propagation medium. More specific examples (a non-exhaustive list) ofthe computer-readable medium would include the following: an electricalconnection having one or more wires, a portable computer diskette, ahard disk, a random access memory (RAM), a read-only memory (ROM), anerasable programmable read-only memory (EPROM or Flash memory), anoptical fiber, a portable compact disc read-only memory (CD-ROM), anoptical storage device, a transmission media such as those supportingthe Internet or an intranet, or a magnetic storage device. Note that thecomputer-usable or computer-readable medium could even be paper oranother suitable medium upon which the program is printed, as theprogram can be electronically captured, via, for instance, opticalscanning of the paper or other medium, then compiled, interpreted, orotherwise processed in a suitable manner, if necessary, and then storedin a computer memory. In the context of this document, a computer-usableor computer-readable medium may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer-usable medium may include a propagated data signal with thecomputer-usable program code embodied therein, either in baseband or aspart of a carrier wave. The computer usable program code may betransmitted using any appropriate medium, including but not limited tothe Internet, wireline, optical fiber cable, radio frequency (RF), etc.

Computer program code for carrying out operations of the presentinvention may be written in an object oriented programming language suchas Java, Smalltalk, C++ or the like. However, the computer program codefor carrying out operations of the present invention may also be writtenin conventional procedural programming languages, such as the “C”programming language or similar programming languages. The program codemay execute entirely on the user's computer, partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Embodiments of the invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

FIG. 1 is a block diagram of an exemplary client computer 102 in whichthe present invention may be utilized. Client computer 102 includes aprocessor unit 104 that is coupled to a system bus 106. A video adapter108, which controls a display 110, is also coupled to system bus 106.System bus 106 is coupled via a bus bridge 112 to an Input/Output (I/O)bus 114. An I/O interface 116 is coupled to I/O bus 114. The I/Ointerface 116 affords communication with various I/O devices, includinga keyboard 118, a mouse 120, a Compact Disk-Read Only Memory (CD-ROM)drive 122, a floppy disk drive 124, and a flash drive memory 126. Theformat of the ports connected to I/O interface 116 may be any known tothose skilled in the art of computer architecture, including but notlimited to Universal Serial Bus (USB) ports.

Client computer 102 is able to communicate with a service providerserver 152 via a network 128 using a network interface 130, which iscoupled to system bus 106. Network 128 may be an external network suchas the Internet, or an internal network such as an Ethernet Network or aVirtual Private Network (VPN). Using network 128, client computer 102 isable to use the present invention to access service provider server 152.

A hard drive interface 132 is also coupled to system bus 106. Hard driveinterface 132 interfaces with a hard drive 134. In a preferredembodiment, hard drive 134 populates a system memory 136, which is alsocoupled to system bus 106. Data that populates system memory 136includes the client computer's 102 operating system (OS) 138 andsoftware programs 144.

OS 138 includes a shell 140 for providing transparent user access toresources such as software programs 144. Generally, shell 140 is aprogram that provides an interpreter and an interface between the userand the operating system. More specifically, shell 140 executes commandsthat are entered into a command line user interface or from a file.Thus, shell 140 (as it is called in UNIX®), also called a commandprocessor in Windows®, is generally the highest level of the operatingsystem software hierarchy and serves as a command interpreter. The shellprovides a system prompt, interprets commands entered by keyboard,mouse, or other user input media, and sends the interpreted command(s)to the appropriate lower levels of the operating system (e.g., a kernel142) for processing. While shell 140 generally is a text-based,line-oriented user interface, the present invention can also supportother user interface modes, such as graphical, voice, gestural, etc.

As depicted, OS 138 also includes kernel 142, which includes lowerlevels of functionality for OS 138, including essential servicesrequired by other parts of OS 138 and software programs 144, includingmemory management, process and task management, disk management, andmouse and keyboard management.

Software programs 144 may include a browser 146 and email client 148.Browser 146 includes program modules and instructions enabling a WorldWide Web (WWW) client (i.e., client computer 102) to send and receivenetwork messages to the Internet using HyperText Transfer Protocol(HTTP) messaging, thus enabling communication with service providerserver 152. Software programs 144 also include a trust client 150. Thetrust client 150 includes code for implementing the processes describedin FIGS. 2 through 5 described hereinbelow. In one embodiment, clientcomputer 102 is able to download the trust client 150 from a serviceprovider server 152.

The hardware elements depicted in client computer 102 are not intendedto be exhaustive, but rather are representative to highlight componentsused by the present invention. For instance, client computer 102 mayinclude alternate memory storage devices such as magnetic cassettes,Digital Versatile Disks (DVDs), Bernoulli cartridges, and the like.These and other variations are intended to be within the spirit andscope of the present invention.

FIG. 2 shows the validation of user credentials submitted to a datasource on behalf of a user by an intermediary with the security tokenservice that issued the credentials. In various embodiments of theinvention, a client 206 running on a system 204 of a user 202 accessesan untrusted intermediary 210 for the provision of data from a datasource 214 residing on a data source server 212. In one embodiment, theuntrusted intermediary is a mashup. As used herein, a mashup isgenerally defined as the combining of content in various formats andfrom multiple sources for presentation as a Web page. In variousembodiments, the content source may be static, such as a block of textor a graphic, or dynamic, such as an application or service thatgenerates content in near-real-time. As an example, a Web service mayprovide a commodities market feed, which is displayed as one element ofa mashup, while another Web service may provide a weather forecast map,which is likewise displayed as another element of the mashup.

In these and other embodiments, the untrusted intermediary 210 attemptsto access the data source 214 on behalf of the user 202. In oneembodiment, the data source 214 is a database. In various embodiments,user credentials are required to access the data provided by the datasource 214. When they are required, the untrusted intermediary 210determines the type and format of user credentials required by the datasource 214. Once determined, the intermediary challenges the user 202 toprovide credentials of the type and format required by the data source214. The user's trust client 208 (e.g. Eclipse Project Higgins,Microsoft Cardspace, etc.) then connects to an authentication serviceand is authenticated. In one embodiment, the authentication service is asecurity token service (STS) 218 operable to generate security tokensimplemented with the WS-Trust protocol familiar to those of skill in theart. Once the user is authenticated, the user's trust client 208requests identification credentials of the required type and format fromthe STS 218.

In one embodiment, the STS 218 can provide identification credentials ofthe required type and format and they are so generated. In anotherembodiment, the STS 218 is not able to provide identificationcredentials of the required type and format, and identificationcredentials of an alternate type and format are generated. Once theidentification credentials are generated, they are provided to theuser's trust client 208, which in turn provides the identificationcredentials to the user's client 206.

The user's client 206 then conveys the identification credentials to theuntrusted intermediary 210. The untrusted intermediary 210 then presentsthe user's identification credentials to an authentication plug-in 216of the data source 214. A determination is then made by theauthentication plug-in 216 whether the provided identificationcredentials are of the type and format required by the data source 214.In one embodiment, if the provided identification credentials are not ofthe required type and format, they are rejected by the authenticationplug-in 216. In another embodiment, the authentication plug-in 216transforms provided identification credentials that are not of therequired format and type into the format and type required by the datasource 214.

The authentication plug-in 216 then processes the providedidentification credentials determine their issuing STS 218. Oncedetermined, the authentication plug-in 216 validates the providedidentification credentials with their issuing STS 218. In oneembodiment, the STS 218 is in a different management domain than theauthentication plug-in 216 and the data source 214 if the provided useridentification credentials are successfully validated, the untrustedintermediary 210 requests the desired data from the data source 214,followed by the provision of the requested data to the untrustedintermediary 210. The requested data is then presented to the user'sclient 206 by the untrusted intermediary 210.

FIGS. 3 a-c are a flowchart for validating user credentials submitted toa data source on behalf of a user by an intermediary with the securitytoken service that issued the credentials. In an embodiment of theinvention, user authentication operations are begun in step 302,followed by the user's client accessing an intermediary for theprovision of data from a data source in step 304. In one embodiment, theintermediary is a mashup. As used herein, a mashup is generally definedas the combining of content in various formats and from multiple sourcesfor presentation as a Web page. In various embodiments, the contentsource may be static, such as a a block of text or a graphic, ordynamic, such as an application or service that generates content innear-real-time. As an example, a Web service may provide a commoditiesmarket feed, which is displayed as one element of a mashup, whileanother Web service may provide a weather forecast map, which islikewise displayed as another element of the mashup.

In step 306, the intermediary attempts to access the data source onbehalf of the user. In one embodiment, the data source is a database. Adetermination is then made in step 308 whether user credentials arerequired to access the data provided by the data source. If not, thenthe intermediary requests the desired data from the data source in step342, followed by the provision of the requested data to the intermediaryin step 344. The requested data is then presented to the user's clientby the intermediary in step 346. In one embodiment, the intermediary isa mashup and the requested data is provided as one element of themashup: A determination is then made in step 348 whether to continueuser authentication operations. If so, then the process continues,proceeding with step 304. Otherwise, user authentication operations areended in step 350.

However, if it is determined in step 308 that the user credentials arerequired to access the data source, then the intermediary determines thetype and format of user credentials required by the data source in step310. Once determined, the intermediary challenges the user in step 312to provide credentials of the type and format required by the datasource. In step 314, the user's trust client (e.g., Higgins, InfoCard,etc.) connects to an authentication service and is authenticated. In oneembodiment, the authentication service is a security token serviceoperable to generate security tokens familiar to those of skill in theart. Once the user is authenticated, the user's trust client requestsidentification credentials of the required type and format from theauthentication service in step 316. A determination is then made in step318 whether the authentication service can provide identificationcredentials of the required type and format. If so, then identificationcredentials of the required type and format are generated in step 320.Otherwise, identification credentials of an alternate type and formatare generated in step 322. Once the identification credentials aregenerated in step 320 or 322, they are provided in step 324 to theuser's trust client, which in turn provides the identificationcredentials to the user's client.

The user's client then conveys the identification credentials to theintermediary in step 326. The intermediary then presents the user'sidentification credentials to an authentication plug-in of the datasource in step 328. A determination is then made by the authenticationplug-in in step 330 whether the provided identification credentials areof the required type and format. If not, then the authentication plug-inprovides instructions to the STS to transform the providedidentification credentials into the format and type required by the datasource in step 332. In one embodiment, the STS performs validationoperations on the provided credentials as part of the transformationprocess. A determination is then made in step 334 whether thetransformation of the provided identification credentials wassuccessful. If not, then a determination is made in step 348 whether tocontinue user authentication operations. If so, then the processcontinues, proceeding with step 304. Otherwise, user authenticationoperations are ended in step 350.

However, if it is determined in step 330 that the providedidentification credentials are of the required type and format, then theauthentication plug-in validates the provided identification credentialswith their issuing authentication service in step 338. In oneembodiment, validation operations are performed on the providedcredentials by the STS as part of the transformation process in step332. A determination is then made in step 340 whether the usercredentials were validated. If not, then a determination is made in step348 whether to continue user authentication operations. If so, then theprocess continues, proceeding with step 304. Otherwise, userauthentication operations are ended in step 350. Otherwise, theintermediary requests the desired data from the data source in step 342,followed by the provision of the requested data to the intermediary instep 344. The requested data is then presented to the user's client bythe intermediary in step 346. A determination is then made in step 348whether to continue user authentication operations. If so, then theprocess continues, proceeding with step 304. Otherwise, userauthentication operations are ended in step 350.

FIG. 4 shows the validation of user credentials submitted to a datasource on behalf of a user by an intermediary with a localauthentication service. In various embodiments of the invention, aclient 206 running on a system 204 of a user 202 accesses an untrustedintermediary 210 for the provision of data from a data source 214residing on a data source server 212. In one embodiment, the untrustedintermediary is a mashup. In these and other embodiments, the untrustedintermediary 210 attempts to access the data source 214 on behalf of theuser 202. In one embodiment, the data source 214 is a database. Invarious embodiments, user credentials are required to access the dataprovided by the data source 214. When they are required, the untrustedintermediary 210 determines the type and format of user credentialsrequired by the data source 214. Once determined, the intermediarychallenges the user 202 to provide credentials of the type and formatrequired by the data source 214. The user's trust client 208 (e.g.,Higgins, InfoCard, etc.) then connects to an authentication service andis authenticated. In one embodiment, the authentication service is asecurity token service (STS) 218 operable to generate security tokensfamiliar to those of skill in the art. Once the user is authenticated,the user's trust client 208 requests identification credentials of therequired type and format from the STS 218.

Once the identification credentials of the required type and format aregenerated, they are provided to the user's trust client 208, which inturn provides the identification credentials to the user's client 206.The user's client 206 then conveys the identification credentials to theuntrusted intermediary 210. The untrusted intermediary 210 then presentsthe user's identification credentials to the data source 214. In oneembodiment, if the provided identification credentials are not of therequired type and format, they are rejected by the data source 214. Thedata source 214 then validates the provided identification credentialswith a local authentication service 418. If the provided useridentification credentials are successfully validated, the untrustedintermediary 210 requests the desired data from the data source 214,followed by the provision of the requested data to the untrustedintermediary 210. The requested data is then presented to the user'sclient 206 by the untrusted intermediary 210.

FIGS. 5 a-b is a flowchart for validating user credentials submitted toa data source by an intermediary with a local authentication service. Inan embodiment of the invention, user authentication operations are begunin step 502, followed by the user's client accessing an intermediary forthe provision of data from a data source in step 504. In one embodiment,the intermediary is a mashup.

In step 506, the intermediary attempts to access the data source onbehalf of the user. In one embodiment, the data source is a database. Adetermination is then made in step 508 whether user credentials arerequired to access the data provided by the data source. If not, thenthe intermediary requests the desired data from the data source in step542, followed by the provision of the requested data to the intermediaryin step 544. The requested data is then presented to the user's clientby the intermediary in step 546. In one embodiment, the intermediary isa mashup and the requested data is provided as one element of themashup. A determination is then made in step 548 whether to continueuser authentication operations. If so, then the process continues,proceeding with step 504. Otherwise, user authentication operations areended in step 550.

However, if it is determined in step 508 that the user credentials arerequired to access the data source, then the intermediary determines thetype and format of user credentials required by the data source in step510. Once determined, the intermediary challenges the user in step 512to provide credentials of the type and format required by the datasource. In step 514, the user's trust client (e.g., Higgins, InfoCard,etc.) connects to an authentication service and is authenticated. In oneembodiment, the authentication service is a security token serviceoperable to generate security tokens familiar to those of skill in theart. Once the user is authenticated, the user's trust client requestsidentification credentials of the required type and format from theauthentication service in step 516. A determination is then made in step518 whether the authentication service can provide identificationcredentials of the required type and format. If not, then adetermination is made in step 548 whether to continue userauthentication operations. If so, then the process continues, proceedingwith step 504. Otherwise, user authentication operations are ended instep 550.

However, if it is determined in step 518 that the authentication servicecan provide identification credentials of the required type and format,then they are generated in step 520 and provided to the user's trustclient. Once the identification credentials of the required type andformat are generated in step 520, the user's trust client in turnprovides the identification credentials to the user's client in step524. The user's client then conveys the identification credentials tothe intermediary in step 526. The intermediary then presents the user'sidentification credentials of the required type and format to the datasource in step 528. The data source then validates the provided useridentification credentials to a local authentication service in step538. In one embodiment, the local authentication service is within thesame management domain and the data source. In another embodiment, theauthentication service that generated the user identificationcredentials is in one management domain and the local authenticationservice is within another management domain.

A determination is then made in step 540 whether the user credentialswere validated. If not, then a determination is made in step 548 whetherto continue user authentication operations. If so, then the processcontinues, proceeding with step 504. Otherwise, user authenticationoperations are ended in step 550. However, if it is determined in step540 that the provided user identification credentials are validated, theintermediary requests the desired data from the data source in step 542,followed by the provision of the requested data to the intermediary instep 544. The requested data is then presented to the user's client bythe intermediary in step 546. A determination is then made in step 548whether to continue user authentication operations. If so, then theprocess continues, proceeding with step 504. Otherwise, userauthentication operations are ended in step 550.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a,” “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of skill in the art withoutdeparting from the scope and spirit of the invention. The embodiment waschosen and described in order to best explain the principles of theinvention and the practical application, and to enable others of skillin the art to understand the invention for various embodiments withvarious modifications as are suited to the particular use contemplated.

Having thus described the invention of the present application in detailand by reference to preferred embodiments thereof, it will be apparentthat modifications and variations are possible without departing fromthe scope of the invention defined in the appended claims.

1. A computer-implementable method for authenticating a user to a datasource, comprising: receiving a request to provide information on behalfof a user; requesting the submission of user authentication credentialsin a desired format; receiving the requested user authenticationcredentials, the user authentication credentials generated in thedesired format by a security token service; validating the received userauthentication credentials with the security token service, thevalidation performed by a back-end service; and providing the requestedinformation, the providing being based on successfully validating thereceived user authentication credentials.
 2. The method of claim 1,wherein: the receiving a request to provide information is to anintermediary; the receiving the requested user authenticationcredentials is from the intermediary; and, the providing the requestedinformation is to the intermediary.
 3. The method of claim 2, whereinthe intermediary is a mashup.
 4. The method of claim 2, wherein the userauthentication credentials are provided to the intermediary by the user,the provision in response to a request from the intermediary for theuser authentication credentials.
 5. The method of claim 1, wherein theuser authentication credentials are not received in the desired formatand are subsequently transformed to the desired format.
 6. The method ofclaim 1, wherein the back-end service is not in the same administrativedomain as the data source.
 7. A system comprising: a processor; a databus coupled to the processor; and a computer-usable medium embodyingcomputer program code, the computer-usable medium being coupled to thedata bus, the computer program code operable to authenticate a user to adata source and comprising instructions executable by the processor andconfigured for: receiving a request to provide information on behalf ofa user; requesting the submission of user authentication credentials ina desired format; receiving the requested user authenticationcredentials, the user authentication credentials generated in thedesired format by a security token service; validating the received userauthentication credentials with the security token service, thevalidation performed by a back-end service; and providing the requestedinformation, the providing being based on successfully validating thereceived user authentication credentials.
 8. The system of claim 7,wherein: the receiving a request to provide information is to anintermediary; the receiving the requested user authenticationcredentials is from the intermediary; and, the providing the requestedinformation is to the intermediary.
 9. The system of claim 8, whereinthe intermediary is a mashup.
 10. The system of claim 8, wherein theuser authentication credentials are provided to the intermediary by theuser, the provision in response to a request from the intermediary forthe user authentication credentials.
 11. The system of claim 7, whereinthe user authentication credentials are not received in the desiredformat and are subsequently transformed to the desired format.
 12. Thesystem of claim 7, wherein the back-end service is not in the sameadministrative domain as the data source.
 13. A computer-usable mediumembodying computer program code, the computer program code comprisingcomputer executable instructions configured for: receiving a request toprovide information on behalf of a user; requesting the submission ofuser authentication credentials in a desired format; receiving therequested user authentication credentials, the user authenticationcredentials generated in the desired format by a security token service;validating the received user authentication credentials with thesecurity token service, the validation performed by a back-end service;and providing the requested information, the providing being based onsuccessfully validating the received user authentication credentials.14. The computer usable medium of claim 13, wherein: the receiving arequest to provide information is to an intermediary; the receiving therequested user authentication credentials is from the intermediary; and,the providing the requested information is to the intermediary.
 15. Thecomputer usable medium of claim 14, wherein the intermediary is amashup.
 16. The computer usable medium of claim 14, wherein the userauthentication credentials are provided to the intermediary by the user,the provision in response to a request from the intermediary for theuser authentication credentials.
 17. The computer usable medium of claim13, wherein the user authentication credentials are not received in thedesired format and are subsequently transformed to the desired format.18. The computer usable medium of claim 13, wherein the back-end serviceis not in the same administrative domain as the data source.
 19. Thecomputer usable medium of claim 13, wherein the computer executableinstructions are deployable to a client computer from a server at aremote location.
 20. The computer usable medium of claim 13, wherein thecomputer executable instructions are provided by a service provider to acustomer on an on-demand basis.